The code changes seems reasonable, but I would like to know more about the motivation. What sort of non-ipython system would uses the <generated tag and would benefit from this?

I can think of a few precedents for generated code:

• dataclasses from the standard library,
• https://github.com/inducer/pyopencl/, and
• https://github.com/inducer/loopy generate code to achieve lower overhead in the invoking GPU code.

Perhaps the more salient point is that, IMO, it is not safe to assume that co_filename corresponds to an "actually accessible" file name. Instead, the default/only safe way to resolve these filenames is via linecache. I learned this the hard way when implementing https://github.com/inducer/pudb.

This makes some sense, but it would help to see an explicit example (i.e. a new test) that demonstrates how line-profiler is missing this case and how this patch fixes it.

I don't understand how dataclasses could be used in a way that would cause trouble. I'd be interested in seeing that example.

We are already using linecache to get the lines (although we clear it if the file exists, which may be the wrong thing to do unless perhaps we are in a reloading IPython context), so I think this patch would just allow code with a filename starting with "<generated" to pass the condition to access its lines via linecache, I would just like a test-case that covers this before I accept the patch.

The specific use case I had in mind was this code generator here: https://github.com/inducer/pytools/blob/7638eacdb2ef690504bade0afc63fc11330b5e85/pytools/py_codegen.py.
In particular, https://github.com/inducer/pytools/blob/7638eacdb2ef690504bade0afc63fc11330b5e85/pytools/py_codegen.py#L66-L68 creates the name for the generated code.
Without this PR, we would have to change the name created there to something like <ipython-input- ... in order to support profiling with line_profiler.

Is it possible to make a MWE that we can use as a test? I don't see an example of how to use PythonFunctionGenerator in a way that makes it obvious how it interacts with line-profiler.

pytools.py_codegen.py isn't yet using linecache, this is being done in inducer/pytools#295 (see e.g. the heuristics needed to support line-profiler: https://github.com/inducer/pytools/pull/295/files#diff-4e20ea316836b98bed526a3a92acb5c9f0aede15dfea15490f6994dcbc21b562R49-R55)
, so I've created an MWE that simulates the intended support, and can be run with the current main branch of pytools:

from pytools.py_codegen import PythonFunctionGenerator
import linecache

cg = PythonFunctionGenerator("test_fn", args=(),
                             decorators=["from line_profiler import profile", "@profile"])
cg("return 42")

fn = cg.get_function()

# Mimic https://github.com/inducer/pytools/pull/295
linecache.cache["<generated code for 'test_fn'>"] = (None, None, ["from line_profiler import profile", "@profile", "def test_fn()", "  return 42"], None)

fn()

Without this PR (#341):

$ export LINE_PROFILE=1
$ python t.py
Timer unit: 1e-09 s

  0.00 seconds - <generated code for 'test_fn'>:2 - test_fn
Wrote profile results to profile_output.txt
Wrote profile results to profile_output_2025-05-16T171619.txt
Wrote profile results to profile_output.lprof
To view details run:
python -m line_profiler -rtmz profile_output.lprof

$ cat profile_output.txt
Timer unit: 1e-09 s

Total time: 2e-06 s

Could not find file <generated code for 'test_fn'>
Are you sure you are running this program from the same directory
that you ran the profiler from?
Continuing without the function's contents.

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
     2
     3
     4         1       2000.0   2000.0    100.0

  0.00 seconds - <generated code for 'test_fn'>:2 - test_fn

With this PR (#341):

$ export LINE_PROFILE=1
$ python t.py
Timer unit: 1e-09 s

  0.00 seconds - <generated code for 'test_fn'>:2 - test_fn
Wrote profile results to profile_output.txt
Wrote profile results to profile_output_2025-05-16T171545.txt
Wrote profile results to profile_output.lprof
To view details run:
python -m line_profiler -rtmz profile_output.lprof

$ cat profile_output.txt
Timer unit: 1e-09 s

Total time: 2e-06 s
File: <generated code for 'test_fn'>
Function: test_fn at line 2

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
     2                                           @profile
     3                                           def test_fn()
     4         1       2000.0   2000.0    100.0    return 42

  0.00 seconds - <generated code for 'test_fn'>:2 - test_fn

Codecov Report

Attention: Patch coverage is 50.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 63.78%. Comparing base (7988790) to head (771d0b7).
Report is 3 commits behind head on main.

@@           Coverage Diff           @@
##             main     #341   +/-   ##
=======================================
  Coverage   63.78%   63.78%           
=======================================
  Files          13       13           
  Lines        1041     1041           
  Branches      228      228           
=======================================
  Hits          664      664           
  Misses        316      316           
  Partials       61       61           

Perfect, that's enough for me to at least accept the PR. It would be good you could do an additional PR where you add this as a test. Otherwise, I'll get to it eventually. It would involve putting that snippet in a some test/*.py file and adding pytools as an optional dependency to requirements/optional.txt. (Eventually we should move to pure pypyroject.toml).

As an aside, I was browsing pytools and was amused to see many of the same ideas in ubelt and other stdlib extension libraries (e.g. boltons, strif, @jaraco 's tools, toolz, etc..) . I'm interested in exploring the question if there is a subset that should be added to the stdlib.